1. Field of the Invention
This invention relates to a database system having a lock control function, and particularly to a lock control method for representing locking of lockable objects.
2. Description of the Related Art
In a database (hereinafter, abbreviated to as DB) system, a lock control facility is provided by a DB management system (hereinafter, abbreviated to as DBMS) for managing a DB in the order to assure consistency in DB when a plurality of transactions are concurrently executed.
The fundamental lock control of the DB is described in "INFORMATION STRUCTURE AND Database, IWANAMI Lectures of Information Science-8, 1983" (Document 1). Here, two different lock modes, or exclusive lock and share lock, are described.
A transaction exclusively locks data being updated. The exclusive lock does not allow other transactions to refer to nor update the locked data. On the other hand, a transaction performs a share lock on data for reference only. The share lock allows the other transactions to refer to the locked data but does not allow them to update it.
The problems associated with the lock control includes a trade off between the transaction concurrence based on the granularity of the locked data unit and the overhead in the lock control processing.
A method, concerning this problem, of efficiently controlling locks by use of lock control rules based on a hierarchy relationship between locked data is described in "Granularity of Locks in a Large Shared DataBase", J. N. Gray, R. A. Lorie and G. R. Putzolu, Proc. 1st International Conference on Very Large Database, 1975 (Document 2).
For example, in a relational database system, since the database consists of a group of tables each of which consists of a group of records, a hierarchy can be constructed in this order (database&gt;table&gt;record). Here, five different lock modes are used which include lock modes having a notion of intention in addition to the above-mentioned two lock modes.
When a transaction performs an exclusive lock on a certain record, it also performs an exclusive intention lock on the table ranking superior to the record. Then, when the other transactions refer to the other records belonging to that table, they should request a for share lock on the table, but the lock does not conflict with the exclusive intention lock. Thus, all transactions can be executed concurrently.
However, when records are updated, the exclusive intention share lock is requested on the table, but the lock conflicts with the exclusive intention lock. Thus, since there is no lock conflict on each record, the overhead for lock control can be reduced.
The relationship among such lock modes is shown in Table 1 (page 434) of Document 2.
In addition, a method of reducing the overhead in a lock control process is described in JP-A-7-191898 (Document 3).
In this method, a table for exclusive control is provided in which predetermined items for exclusive control are registered, and when values of the corresponding items are being locked, the lock control table is checked for the registration, so that the amount of input data for lock control can be reduced and that the overhead for lock control can be reduced.
A model capable of a benchmark test in a DB system presented in "The 007 Benchmark", Carey Michael J., DeWitt David J., Naughton Jeffery F., Proc. ACM SIGMOD Conference, June 93 (Document 4) has a mode in which data of one hundred million pieces or more can be treated.
In this case, when the data length of one record of the lock management table is assumed to be about 100 bytes, simultaneous lock control on data of one hundred million pieces or more will need a memory region of 10 gigabytes or more. In this mode, lock control is also made in a data page unit having a plurality of pieces of data, so that the number of records in the lock management table can be reduced.